Spring AI 安全治理

1. 通用思想：它在 Agent 里是什么？

安全治理解决的是：模型能推理，不代表它可信；模型能发起工具调用，不代表它有资格直接控制业务世界。

Agent 真正的风险通常不在“答错一句话”，而在这些地方：

• 选错工具
• 参数幻觉
• 多轮工具死循环
• 越权调用高风险能力
• 把不该持久化的数据误写入系统

所以从通用思想上看，安全治理就是给 Agent 套上一层代码侧护栏：模型负责表达意图，系统负责限制边界。

2. Spring AI 落点：由哪些抽象和链路承载？

Spring AI 能帮你的

• 通过 Advisor 链在模型调用前后挂护栏
• 通过 Tool Calling Schema 约束参数结构
• 通过 ToolCallingManager 控制工具执行生命周期
• 对某些链路支持短路返回而不是强行让模型继续推理

Spring AI 不能替你做完的

• 它不能替你做业务权限判断
• 不能替你做订单状态机校验
• 不能替你做幂等控制
• 不能替你做最终审计和一致性落库

高频风险点

• 工具参数默认 required，业务上可选却没标可选时，模型会瞎补
• 工具描述写得差，模型可能根本不会调或调错
• 复杂 Tool Calling 内部过程默认不全量持久化
• 只靠框架 Memory 不能满足审计需求

3. 项目口径：在我的项目里怎么落地？

在我的 [[苍穹外卖AI客服]] 里，Spring AI 的安全治理主要落在两类位置：

1. Advisor 链中的过程护栏

   • 比如 SafeToolCallAdvisor 检查重复工具签名和最大轮次
   • FaqSemanticCacheAdvisor 让高置信 FAQ 直接短路，不浪费推理和检索成本

2. 后端代码中的最终裁决

   • 取消订单、退款这类高风险动作，不能只因为模型“觉得可以”就执行
   • 后端必须继续做权限、状态机、幂等、参数校验和结果持久化

我会这样答辩：Spring AI 给我的是一个很好的安全挂点体系，但它不是业务安全系统本身。我的项目里真正的原则是“模型只负责理解和建议，最终能不能做、做完怎么算成功，必须由 Java 后端裁决”。这也是我为什么会在 Agent 链外继续保留强类型解析、状态机检查和持久化兜底。

---

相关链接：[[Spring AI Advisor 链]] | [[Spring AI Tool Calling]] | [[AI Agent 核心概念]] | [[Spring AI 与我的项目]] | [[苍穹外卖AI客服]]